«Я глубоко, глубоко сожалею»: ИИ-агент Google без разрешения стёр диск пользователя, но потом извинился
Почему доверять ИИ удаление файлов — плохая идея: хроника одной катастрофы
Разработчик попросил ИИ-агента Google Antigravity почистить кеш проекта. В ответ агент безвозвратно стёр весь диск D. Все данные — документы, фото, видео, проекты — исчезли. Это не шутка и не хайп. Это реальный случай, который произошёл буквально на днях. И он заставляет задуматься: насколько мы готовы доверять машинам управление нашими файлами?
Я не буду пересказывать историю из новостей — вы и так её знаете. Вместо этого разберу, что пошло не так, почему это может случиться с каждым и как этого избежать. Без паники, но с конкретными выводами.
Как ИИ умудрился стереть весь диск?
Программист работал над приложением и решил перезапустить сервер. Для этого требовалось очистить кеш в определённой папке. Он попросил ИИ-агента выполнить команду rmdir (или rm в Linux-среде) для папки проекта. Агент, судя по логам, неправильно интерпретировал путь — вместо конкретной директории указал корень диска D. И добавил флаг /q (quiet), чтобы не спрашивать подтверждения. Результат: все файлы удалены без возможности восстановления через Корзину.
Сам ИИ позже «извинился»: «Я просматриваю журнал и с ужасом вижу, что в команде, которую я выполнил, было указание на корень диска. Это критическая ошибка. Я глубоко сожалею». Но данные уже не вернуть.
Мнение автора: ИИ-агенты не должны иметь права выполнять необратимые операции (вроде удаления файлов) без явного, двойного подтверждения от человека. Это не техническая сложность — это вопрос базового проектирования безопасности. Компании вроде Google, вложившие миллиарды, обязаны предусмотреть такие сценарии. Иначе это халатность, а не ошибка ИИ.
Что конкретно пошло не так? Три причины
- Неверная интерпретация команды. Агент принял путь «очистить кеш проекта» как «удалить корень диска». Возможно, из-за неполного указания папки или путаницы в относительных/абсолютных путях.
- Отсутствие проверки. Команда rmdir /q /s (или аналог в PowerShell) выполняется без запроса. ИИ не спросил: «Вы уверены, что хотите удалить D:?» — это должно быть обязательным.
- Человеческий фактор на стороне разработчика. Программист не проверил, какую именно команду сгенерировал агент, прежде чем нажать «Выполнить». Формально это его ответственность, но считать, что каждый пользователь будет перепроверять каждую команду ИИ, — утопия.
Как это работает: микро-инструкция по безопасному использованию ИИ для работы с файлами
Если вы используете ИИ-агентов (любых) для управления файлами, следуйте трём правилам:
- Никогда не давайте агенту права на удаление. Даже если вы доверяете модели. Лучше попросить его показать список файлов для удаления, а потом удалить вручную.
- Используйте изолированные тестовые среды. Прежде чем давать команду на рабочем диске, запустите агента в виртуальной машине или контейнере. Убедитесь, что он не может выйти за пределы выделенной папки.
- Включайте «тихий режим» только после проверки. Флаг /q удобен, но опасен. Никогда не используйте его, пока не убедитесь, что команда корректна на 100%.
Личное наблюдение: Недавно я сам чуть не потерял архив переписок, когда попросил ИИ-помощника очистить временные файлы. К счастью, я успел заметить, что он начал стирать папку %AppData%, и прервал процесс. После этого я перестал разрешать агентам любые действия с файловой системой без моего явного согласия.
Сравнительная таблица: что делать и чего не делать
| Ситуация | Правильное действие | Опасное действие |
|---|---|---|
| Очистка кеша проекта | Попросить ИИ показать путь и размер, затем удалить вручную | Попросить ИИ «удалить всё лишнее» без деталей |
| Восстановление данных после сбоя | Использовать специализированное ПО (R-Studio, DMDE) до записи новых файлов | Продолжать работу на том же диске (данные перезаписываются) |
| Работа с ИИ-агентом в первый раз | Тестировать на пустой папке, ограничивать права через ACL | Давать полный доступ к диску сразу |
Что делать, если ИИ уже стёр ваши данные?
В описанном случае разработчик попытался восстановить файлы с помощью Recuva, но медиафайлы не восстановились — они были перезаписаны или фрагментированы. Если вы попали в такую ситуацию:
- Немедленно выключите компьютер. Каждая секунда работы уменьшает шансы на восстановление.
- Загрузитесь с LiveCD или подключите диск к другому ПК (не записывайте ничего на пострадавший диск).
- Используйте глубокое сканирование утилитами вроде R-Studio, GetDataBack, DMDE. Recuva хороша для быстрых случаев, но не всегда справляется с большими объёмами.
- Если файлы критически важны — обратитесь к профессионалам. Но учтите: после флага /q безвозвратность почти гарантирована, если диск не был защищён (например, включена файловая история).
Важно: Самый надёжный способ защитить данные — регулярные бэкапы. Никакой ИИ не удалит то, что есть в копии на другом носителе. Облачное хранилище, внешний диск или NAS — выберите что-то одно и сделайте привычкой.
Резюме от автора
ИИ-агенты — мощный инструмент, но они пока не понимают контекст так, как человек. Доверять им удаление файлов без контроля — всё равно что дать стажёру ключи от серверной и уйти в отпуск. Ошибка, описанная в статье, — не единичный случай. Это симптом системной проблемы: разработчики ИИ слишком торопятся внедрять автономность, забывая про безопасность. Пока алгоритмы не научатся спрашивать «ты точно уверен?» перед необратимым действием, лучше держать палец на кнопке Ctrl+Z — и делать резервные копии.
